System and method for originating a call via a circuit-switched network from a user equipment device

ABSTRACT

In one aspect, an application server (AS) node comprises a processor configured to receive a first SIP Invite request from the UE device, the first SIP Invite request having call information which includes a URI of a called party and data indicating that the first SIP Invite request is for a bearer over a circuit-switched (CS) network. An E.164 number is associated with the call information in the first SIP Invite request and a SIP response including the E.164 number is sent to the UE device in response to receiving the first SIP Invite request. When a call setup message including the E.164 number received from the CS network, the received E.164 number is verified if it is valid and if so, the call information is identified based on the E.164 number and is sent to the called party via a second SIP Invite request.

CLAIM OF PRIORITY UNDER 35 U.S.C. §120 & 37 C.F.R. §178

This nonprovisional application is a continuation application claimingthe benefit of the following prior United States patent applicationentitled: “SYSTEM AND METHOD FOR ORIGINATING A SIP CALL VIACIRCUIT-SWITCHED NETWORK FROM A USER EQUIPMENT DEVICE”, application Ser.No. 12/732,041, filed on Mar. 25, 2010, pending, which is a continuationof application Ser. No. 11/740,102, filed on Apr. 27, 2007, now issuedas U.S. Pat. No. 7,710,950, which in turn is a Continuation-In-Part(CIP) of and claims priority to “SYSTEM AND METHOD FOR EFFECTUATING ASIP CALL IN A NETWORK ENVIRONMENT INCLUDING IMS”, application Ser. No.11/347,874, filed on Feb. 6, 2006, now issued as U.S. Pat. No. 7,830,868and is also a CIP of and claims priority to “SYSTEM AND METHOD FORMANAGING CALL CONTINUITY IN IMS NETWORK ENVIRONMENT USING SIPMESSAGING”, application Ser. No. 11/542,462, filed on Oct. 3, 2006, nowissued as U.S. Pat. No. 7,995,565, each of which foregoing applicationsis hereby incorporated by reference herein.

CROSS REFERENCE TO RELATED APPLICATION(S)

This patent applicationThis application is a reissue of U.S. Pat. No.8,989,179, which discloses subject matter that is related to the subjectmatter of U.S. patent application entitled: “SYSTEM AND METHOD FORMANAGING CALL ROUTING IN A NETWORK ENVIRONMENT INCLUDING IMS”,application Ser. No. 11/328,875, filed on Jan. 10, 2006, now issued asU.S. Pat. No. 7,769,000 which is hereby incorporated by referenceherein.

FIELD OF THE TECIINOLOGY

The present patent disclosure generally relates to call routing incommunications networks. More particularly, and not by way of anylimitation, the present patent disclosure is directed to a system andmethod for managing call routing in a network environment including acircuit-switched (CS) network and an IP multimedia subsystem (IMS)network, wherein a CS-originated IP call (e.g., based on the SessionInitiation Protocol or SIP) is to be routed using the IMS networkinfrastructure.

BACKGROUND

Today's advanced communication devices are capable of seamlesslyoperating in a packet-switched IP network domain (using, for example,wireless LAN (WLAN) or Wi-MAX networks, etc.) as well as acircuit-switched cellular network domain. To facilitate such capability,current 3^(rd) Generation Partnership Project (3GPP) standards specify anew, IP-based network architecture referred to as the IP multimediasubsystem (IMS) which allows a communication device (referred to as userequipment or UE) to initiate calls to both IP-only subscribers andconventional circuit-switched telephony subscribers using either of thedomains. There may arise a situation, however, where a wireless device,i.e. a UE device in 3GPP, is able to make a voice call to a called partyusing the circuit-switched network domain only because either nopacket-switched network is available or the available networks in thepacket-switched domain do not support the Voice-over-IP (VoIP) service.In such a situation, if the called party happens to be an IP-onlysubscriber and is identified with a Uniform Resource Indicator (URI),the originating UE may not be able to make the IP-based call since theUE device can effectuate only E.164 number-based calls while operatingin the circuit-switched domain.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the embodiments of the present patentdisclosure may be had by reference to the following Detailed Descriptionwhen taken in conjunction with the accompanying drawings wherein:

FIG. 1 depicts a network environment including circuit-switched networkinfrastructure and IM multimedia subsystem (IMS) infrastructure whereinan embodiment of the present patent disclosure may be practiced;

FIG. 2 depicts a flowchart associated with one or more exemplaryembodiments of the present patent disclosure;

FIGS. 3A and 3B depict exemplary message flow diagrams for originating aSIP call by employing a SIP Invite message with a SIP-URI of the calledparty in the Request-URI, for mapping with a dynamically-allocated IPmultimedia routing number (IMRN) at an application server (AS) node; and

FIG. 4 depicts a block diagram of an embodiment of a communicationsdevice operable for purposes of the present patent disclosure.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Methods and apparatus for originating a Session Initiation Protocol(SIP) call from a user equipment (UE) device in a network environmentincluding a circuit-switched (CS) network and an IP multimedia subsystem(IMS) network to a called party are disclosed. When the SIP call isoriginated from the UE device in the CS network domain, a SIP Invitemessage which includes a SIP Uniform Resource Indicator (URI) or Tel URIof the called party is sent from the UE device to an application server(AS) node in the IMS network. At the AS node, a pool of E.164 numbersare maintained as IP multimedia routing numbers (IMRNs) which areutilized for mapping to or otherwise associating with called party URIs.The AS node dynamically allocates a select E.164 number with respect tothe called party's URI received from the UE device, and returns it tothe UE device in a SIP Response message, e.g., a SIP 380 (AlternativeService) message. Subsequently, the dynamically-allocated E.164 numberis sent from the UE device in a call setup message for identification ofthe URI and other suitable call information at the AS node. Thus, thedynamically-allocated E.164 number is utilized for routing the SIP calltowards the called party upon interrogating the SIP URI-IMRN mapping,whereupon it may be released back to the pool of IMRNs for future use.Appropriate timers may be provided at the device and AS node endpointsso that it can be verified whether a call reference number associatedwith the call remains valid (e.g. it has not timed out) or thedynamically-allocated IMRN remains valid (e.g. it has not timed out).Optionally, the released IMRN may be quarantined for a period of time.

A system and method of the present patent disclosure will now bedescribed with reference to various examples of how the embodiments canbest be made and used. Like reference numerals are used throughout thedescription and several views of the drawings to indicate like orcorresponding parts, wherein the various elements are not necessarilydrawn to scale. Referring now to the drawings, and more particularly toFIG. 1, an exemplary network environment 100 is depicted wherein anembodiment of the present patent disclosure may be practiced for routinga SIP call originated by a UE device in a circuit-switched network ordomain. As depicted, the network environment 100 includes an accessspace 104 comprised of a number of access technologies available to aplurality of UE devices 102-1 through 102-N. For purposes of the presentdisclosure, a UE device may be any tethered or untethered communicationsdevice, and may include any personal computer (e.g. desktops, laptops,palmtops, or hand-held computing devices) equipped with a suitablewireless modem or a mobile communications device (e.g. cellular phonesor data-enabled handheld devices capable of receiving and sendingmessages, web browsing, et cetera), or any enhanced PDA device orintegrated information appliance capable of email, video mail, Internetaccess, corporate data access, messaging, calendaring and scheduling,information management, and the like. Preferably, the UE device iscapable of operating in multiple modes in that it can engage in bothcircuit-switched (CS) as well as packet-switched (PS) communications,and can transition from one mode of communications to another mode ofcommunications without loss of continuity.

The access space 104 may be comprised of both CS and PS networks, whichmay involve wireless technologies, wireline technologies, broadbandaccess technologies, etc. For example, reference numeral 106 refers towireless technologies such as Global System for Mobile Communications(GSM) networks and Code Division Multiple Access (CDMA) networks,although it is envisaged that the teachings hereof may be extended toany 3^(rd) Generation Partnership Project (3GPP)-compliant cellularnetwork (e.g. 3GPP or 3GPP2) as well. Reference numeral 108 refers tobroadband access networks including wireless local area networks orWLANs, Wi-MAX networks as well as fixed networks such as DSL, cablebroadband, etc. Also exemplified as part of the access space 104 is theconventional wireline PSTN infrastructure 110.

An IP multimedia subsystem (IMS) core network 112 is coupled to thevarious access networks set forth above, including any CS-basednetworks. As is well known, the IMS standard defined by the 3GPP isdesigned to allow service providers manage a variety of services thatcan be delivered via IP over any network type, wherein IP is used totransport both bearer traffic and SIP-based signaling traffic. Broadly,IMS is a framework for managing the applications (i.e. services) andnetworks (i.e. access) that is capable of providing multimedia services.IMS defines an “application server” to be the network element thatdelivers services subscribers use, e.g. voice call continuity (VCC),Push-To-Talk (PTT), IMS Centralized Services (ICS) etc. IMS managesapplications by defining common control components that each applicationserver (AS) is required to have, e.g. subscriber profiles, IMS mobility,network access, authentication, service authorization, charging andbilling, inter-operator functions, and interoperation with the legacyphone network.

It should be understood that whereas IMS is defined by the 3GPPstandards body which mainly addresses GSM networks, another group,3GPP2, is involved in defining a closely analogous architecture referredto as Multimedia Domain (MMD). MMD is essentially an IMS for CDMAnetworks, and since MMD and IMS are roughly equivalent, the term “IMS”may be used in this present patent disclosure to refer collectively toboth IMS and MMD where applicable.

Continuing to refer to FIG. 1, reference numerals 114-1 to 114-N referto a plurality of AS nodes operable to support various services, e.g.VCC, PTT, ICS etc. as alluded to hereinabove. Furthermore, in order toeffectuate call control of a SIP call using CS as the voice bearer, oneof the AS nodes, e.g. AS 114-(N-1), may be provided for implementingfunctionality referred to as IMS Centralized Services Control Function(ICCF). ICCF is operable as an IMS application server element thatresides in the home IMS network and tracks all call sessions and relatedmobile Voice-over-IP (VoIP) bearer traffic, between CS and IMS domains.Additional details regarding the functionality of AS 114-(N-1) may befound in the pending U.S. patent application entitled “SYSTEM AND METHODFOR MANAGING CALL ROUTING INA NETWORK ENVIRONMENT INCLUDING IMS”,application Ser. No. 11/328,875, filed Jan. 10, 2006, referencedhereinabove.

Additionally, another AS node, AS 114-N, is provided as part of the coreIMS network 112 for facilitating routing of IP/SIP calls originated byone of the UE devices in the CS domain while connectivity in the PSdomain is not available or the available PS networks are not capable ofsupporting the VoIP service (e.g. due to bandwidth limitations).Appropriate database structures (e.g. DB 122), timer mechanisms (e.g.timer 124) and suitable logic 126 may be provided in association with AS114-N for purposes of configuring and managing a pool of IP multimediarouting numbers (IMRNs) from which a select IMRN may bedynamically-allocated for purposes of SIP call routing as will bedescribed in greater detail below.

In accordance with the teachings of the present patent disclosure, AS114-N is preferably provided with appropriatelogic/structure/software/firmware module(s), such as call continuitycontrol function (CCCF) 116, network domain section (NeDS) 118, and gsmservice capability feature (gsm SCF) 120 for performing the following:maintaining a pool of E.164 numbers that are operable as IMRNs whichterminate on the AS node, wherein a select E.164 number may be mapped tothe received information in the SIP Invite message, including but notlimited to, a called party's SIP URI or Tel URI, P-Preferred Identity,Privacy Indication, and Network Access Info header; dynamicallyallocating the select E.164 number to a received called party's URI(e.g. SIP URI or Tel URI) and other received information and providingthe select E.164 number to the originating UE device via a SIP Responsemessage; verifying that the select E.164 number has not timed out whenthat select E.164 number is returned (via conventional CS call setup) toAS 114-N for effectuating a SIP call session with respect to the calledparty; and optionally, quarantining the select E.164 number for a periodof time upon releasing it back to the pool for future use.

Note that E.164 is indicative of the International TelecommunicationsUnion (ITU) telephone numbering plan, which specifies how and by whomtelephone numbers are assigned. The format and notation of E.164telephone numbers is specified in the ITU standard E.123, for example.To manage a pool of dynamically-allocable IMRNs, the AS node (e.g. AS114-N) may be configured in a number of ways with respect to the E.164numbers. For example, a particular E.164 number may be provided as a“starting address” number of an IMRN range. Another E.164 number mayoperate as a range delimiter with respect to the IMRN range. To allowflexibility, it may be desirable to provide for different pools of IMRNsto be configured from different number ranges. Further, appropriatetimer mechanism(s) may be implemented at AS 114-N in order to ensurethat the allocated IMRNs remain valid (e.g. they have not timed out,that is, they are used within appropriate time limits) or suitablequarantine times are applied. As will be described in detail below,management of timers associated with IMRNs at AS 114-N and timersassociated with call reference numbers at the originating UE deviceallows for dynamic provisioning of IMRNs that could be used foreffectuating SIP calls by the UE device operating in the CS domain.

FIG. 2 depicts a flowchart of an exemplary embodiment of an overallmethodology of the present patent disclosure for effectuating aCS-originated SIP call by a UE device with respect to a called partyidentified by a URI (e.g. a SIP URI or Tel URI). The SIP call isinitiated by the end user of the UE device, or the originating party.Preferably, the originating party either enters the URI via a suitableinterface (e.g. MMI) or selects it from a list stored in the UE. As iswell known, a typical SIP address may take on the form of sip:<username>@<hostname>, which may include additional syntax elements andparameters such as those described in, e.g. RFC 3261 entitled: SIP:Session Initiation Protocol and Internet Draft entitled Obtaining andUsing Globally Routable User Agent (UA) URIs (GRUU) in the SessionInitiation Protocol (SIP) (draft-ietf-sip-gruu-06) (Expires: Apr. 23,2006).

Note that a “Tel URI” is presently defined in Request For Comments (RFC)3966 (December 2004). Some examples of Tel URIs are as follows: (1) tel:+1-201-555-0123: This URI points to a phone number in the United States.The hyphens are included to make the number more human readable; theyseparate country, area code and subscriber number; (2) tel:7042;phone-context=example.com: The URI describes a local phone numbervalid within the context “example.com”; and (3) tel: 863-1234;phone-context=+1-914-555: The URI describes a local phone number thatis valid within a particular phone prefix.

At block 202, various pieces of information relating to the SIP call(which may be collectively referred to as “call information” herein).The call information may include information such as a call referencenumber associated with the call, called party's SIP URI (or, the B-URI),Opaque parameter (if available), GRID parameter (if available),additional URI-related information (e.g. display name), calling party'sSIP URI (or, the A-URI), Opaque parameter, privacy indicator, networkaccess info header etc. If the calling party sends a B-URI thatcomprises anAddress of Record (AOR) as well as Opaque and GRIDparameters, they will be provided as part of the call information.Additionally, if the calling party sends its own URI comprising AOR,Opaque and GRID parameters, they will also be provided in the callinformation.

A timer may be initiated on the UE device that is used for monitoring atleast a portion of the call information that is transmitted by theoriginating UE device as described above. In particular, the timer maybe implemented for monitoring the elapsed time since a particular callreference number is generated and forwarded to the IMS network node. Atthe IMS network node, an IMRN selected from the pool of IMRNs isdynamically associated with respect to the call reference number,wherein the IMRN is mapped to the at least a portion of the callinformation, e.g. the received called party's SIP URI (block 204). Insome embodiments, the IMRN may be mapped to all the received SIP callinformation. Also, a timer may be started at the network node formonitoring a time-to-live variable associated with thedynamically-allocated IMRN.

Thereafter, the dynamically-allocated IMRN is provided to the UE devicevia a SIP 380 (Alternative Service) Response message. Upon receipt ofthe SIP 380 (Alternative Service) Response message which includes thedynamically-allocated IMRN at the UE device, the elapsed time associatedwith the call reference number is monitored to ensure that it is notstale (block 206). The dynamically-allocated IMRN is accepted by the UEdevice if the time elapsed satisfies a select condition, e.g. within atime-to-live value (block 208). In response, appropriate call setup isthen initiated by the UE device using the dynamic IMRN, whereby theaccepted IMRN is returned to the AS node since it terminates thereat.Upon receipt of the IMRN at the AS node, its time-to-live variable ismonitored to ensure that it has not timed out (block 210). Thereafter,the called party's SIP URI or Tel URI (and any other suitable SIPinformation originally received that is mapped to thedynamically-allocated IMRN) is utilized by the AS node for effectuatingthe SIP session with the called party by producing and sending a SIPInvite message (e.g. inserting the A-party URI, Privacy indicator,B-party URI, Opaque parameter, etc., in the SIP Invite message andcausing it to be sent to the called party). In one implementation, thedynamic IMRN may optionally be returned back to the pool of IMRNs,wherein it may be quarantined for a certain period of time before it isreused or becomes available for future use (block 212).

Based on the foregoing, those skilled in the art will appreciate thatwhen the call information, i.e. called party's SIP URI or Tel URI, callreference number, etc. is sent by the UE device to the serving AS node,appropriate logic at the AS node may create a record that maps thereceived call information to an E.164-based IMRN, which is transmittedback to the UE device. Upon correlating the IMRN with the call referencenumber, the UE sets up a call using the IMRN that terminates on the ASnode. The IMRN is then interrogated against the record to retrieve thecalled party's URI for establishing a SIP session with the called party(i.e. between the calling party (UE device) identified by the A-partyaddress and the called party identified by the B-party address).

It should be further recognized by those skilled in the art that themessage flow between the UE device and the home IMS network's AS nodemay be mediated through a number of other appropriate networkinfrastructure elements, and may be implemented in a number of waysdepending on the device capabilities as well as the network features andprotocols being used. Typically, the message flow may be mediated vianetwork elements such as a mobile switching center (MSC) and a mediagateway control function (MGCF) element disposed between the UE deviceand its home IMS AS node operable to facilitate CS-originated SIP calls.

FIG. 3A depicts a message flow embodiment 300A for effectuating aCS-originated SIP call based on dynamic IMRN allocation where SIPmessaging is implemented. A wireless UE device 302 having the CS domainand IMS domain modes of functionality is operable to generate a SIPInvite message 312 towards an application server (AS) node 308 inresponse to detecting that a SIP call is being initiated from UE device302 in the CS domain. As described earlier, the SIP Invite message 312includes applicable call information such as call reference number,called party's SIP URI, additional URI information, and the like, e.g.A-party AOR in the P_Preferred Identity, Privacy Indicator Opaqueparameter, GRID parameter, etc. As described above, the originatingparty either enters the URI (or SIP address) or Tel URI via a suitableinterface (e.g. MMI) or selects it from a list stored in the UE toinitiate the call.

The SIP Invite message 312 may further include an indicator in anindicator field that indicates whether the message is for acircuit-switched (CS) mobile-originated (MO) call (i.e. whether UEdevice 302 intends to make this call via CS domain). For example, a newNetwork-Access-Info value such as “GERAN-CS” may be utilized.Alternatively, a new feature tag or new URI parameter may be provided inthe SIP Invite message. Note, however, that an indication may be assumedmerely from the inclusion of the SIP URI or Tel URI of the called party(“B-party”) in the SIP Invite message. In one preferred embodiment, theTARGET address in the SIP Invite message is populated with the SIP URIor Tel URI of the called party or B-party. In this case, a SIP URI fieldof the SIP Invite message is populated with a public service identifier(PSI) of the AS node. A cause value in the SIP Invite message will beset appropriately to indicate that a radio bearer channel for thesession is to be established over the CS domain.

A suitable timer mechanism 310 may be initiated at the UE device inorder to monitor a time-to-live variable associated with the callreference number. It should be appreciated that this timer may beprovided in addition to normal SIP timers as this operation is known toprovide a SIP 380 Response with specific information within a certaintimeframe.

Responsive to the Invite message 312, which may be mediated via I-CSCFand/or S-CSCF nodes. AS node 308 disposed in the user's home IMS networkis operable to launch SIP-URI logic 313 for generating and populating asuitable SIP 380 (Alternative Service) Response message (e.g. SIP 380Response message) as described above. Upon verifying that the user isallowed to do a SIP call and the Invite message includes the proper CSMO indicator, the network node (in this example, the IMS AS node)dynamically allocates a select IMRN mapped to the call information orparameters (e.g. A-party AOR in the P_Preferred Identity, PrivacyIndicator Opaque parameter, GRID parameter, etc.) and returns it back toUE device 302 via SIP 380 message 316. Again, the dynamically-allocatedIMRN may be referred to as an IMS Centralized Service Routing Number or“ICSRN.” The dialog information contained in the Invite Header or in thebody of the Invite may be used to correlate the call.

A suitable timer mechanism may be started (block 314) at the AS node 308in order to monitor a time-to-live variable associated with thedynamically allocated IMRN. After verifying that the call reference hasnot timed out based on the UE device's timer mechanism, responsive toreceipt of the SIP 380 Response message 316, UE device 302 initiates acall setup message 320 that includes the dynamic IMRN (or ICSRN). Inresponse, MSC 304 generates an Initial Address Message (IAM) 322 towardsMGCF 306. A SIP Invite message 324 that contains the IMRN is generatedby MGCF 306 towards the AS node 308, which then uses the IMRN mappingfor establishing the SIP session or call to the called party (notshown). It is recognized that various intermediate SIP messages andresource allocation/reservation negotiations may take place between MGCF306 and the called party subsequent to SIP Invite 324, which are notdescribed in particular detail herein. Also, additional ISUP messagingthat may take place before a bearer path is established between the UEdevice 302 and the called party understood by those skilled in the artis not shown herein.

Upon receipt of the dynamically-allocated IMRN via SIP Invite 324 at theAS node 308, the timer mechanism may be stopped (block 326) to verify ifthe IMRN has timed out. If timed-out, the SIP Invite message may bediscarded and the call routing process may be terminated. If the IMRNhas not timed out, the AS node 308 may establish the SIP session basedon the IMRN correlation. After using the IMRN for correlation, it may bereturned to the IMRN pool, wherein a quarantine timer may be started(block 328) such that the IMRN is prohibited from further use until thequarantine timer is stopped after a period of time (block 330).

As pointed out previously, the timer mechanism at the device side mayalso be used to ensure that the call reference number has not timed out(e.g., using the timer mechanism 318), which reference number is used bythe UE device to correlate the information received from the networknode (e.g., dynamic IMRN). If the timer expires before the samereference number is received back from the network node, the UE devicemay reattempt the call process a predetermined number of times (e.g.five attempts), after which if no response has been received, the callprocedure may be deemed to have failed. In other words, if the UE devicereceives a reference number that is no longer valid, it may be discardedand the call procedure may be terminated.

FIG. 3B depicts a message flow diagram 300B for a mobile-originated SIPcall by employing a SIP Invite message with a SIP-URI in the Request-URIwherein certain intermediary nodes in a home network 350 areexemplified. Similar to the flow diagram embodiment 300A describedabove, UE device 302 is operable to generate a SIP Invite message 356towards I-CSCF 352, wherein the SIP Invite message includes a SIP-URI ofthe called party contained in the TARGET field. This Invite message ispropagated to AS node 308 either directly as SIP Invite 362 or viaS-CSCF 354 by way of SIP Invite messages 358 and 360. As describedpreviously, SIP 380 (Alternative Service) Response message 364 havingthe ICSRN is generated by AS node 308 towards S-CSCF 354, which is thenpropagated to UE device 302 via SIP response 366. A call setup message368 having the ICSRN is provided to MSC 304, which initiates a CSorigination procedure 370. IAM messaging 372 from MSC 304 towards MGCF306 is operable to generate SIP Invite 374 towards I-CSCF 352, which maybe directly propagated to AS node 308 as Invite message 380 having theICSRN. Alternatively, I-CSCF 352 first provides a SIP Invite 376 toS-CSCF 354 which then propagates a SIP Invite 378 to AS node 308.Regardless, once the ICSRN is received at the AS node 308, appropriatecall correlation is made to establish the SIP call between the UE andthe called party.

Note that, in one variation of the technique described in relation toFIGS. 2, 3A, and 3B, the E.164 number is not dynamically allocated butrather merely identified, calculated, or otherwise selected inaccordance with any suitable algorithm.

Elaborating on the techniques of the present disclosure in furtherdetail, when the UE device detects that it needs to invoke CS callorigination, it may produce and send a SIP Invite message to an R-URIthat is known to terminate at the IMS centralized services node. In thiscase, the Target parameter of the SIP Invite message is populated withthe B party address (SIP URI or Tel URI) and the Cause value of the SIPInvite message is set to indicate that the call needs to be set up overCS. Alternatively, the R-URI may be populated with the B-party address,and may further include an indicator in an indicator field thatindicates whether the message is for a circuit-switched (CS)mobile-originated (MO) call (i.e. whether UE device 302 intends to makethis call via the CS domain). For example, a new Network-Access-Infovalue such as “GERAN-CS” may be utilized. Alternatively, a new featuretag or new URI parameter may be provided in the SIP Invite message. Inthe first case, the SIP Invite message contains the GRUU of theUE/Public ID combination. The P-Preferred-ID is set to the calling lineidentity (CLI) associated with the user or subscriber of the UE devicefor identification in the CS network. The B-Party Public user address(Tel URI, SIP URI) is set in SIP URI Target parameter, and the causevalue indicates CS bearer required=YYY.

Note that when the Target parameter is used to carry the B partyaddress, the SIP R-URI may be one of many that has been provisioned inthe UE device to indicate the ICCF. If so, the UE device could chooseone of these at random, the URI could have some indicia that identify apriority order.

An example is provided below:

INVITE sip:icenetworknode@example.com;\target=sip:+15555551002%40example.com;user=phone;\ cause=YYY  SIP/2.0P-Preferred-Identity: <tel: +1-555-1001> P-Access-Network-Info:3GPP-GERAN; Privacy: none From:Alice<sip:+15551001@example.com;user=phone>;tag=9fxced76sl Supported: gruuTo: sip:+15555551002@example.com;user=phone Call-ID:c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 70 Contact:<sip:alice@192.0.2.1> ;+sip.instance=“<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>” Content-Type: application/sdp Content-Length: *Bodylength goes here*

If the R-URI is set to the B-party, the invite shall contain the GRUU ofthe UE/Public ID combination. The P-Preferred-ID shall be set to thecalling line identity that the user wants to be known as in the CSnetwork. The Network-Access-Info header shall be set to a value toindicate that the call is SIP controlled, but the radio bearer goes overthe CS domain, in this example the setting is 3GPP-GERAN-CS, anotherexample could be 3GPP-UTRAN-CS.

An example is provided below:

INVITE sip: sip:+15555551002%40example.com;user=phone;\ SIP/2.0P-Preferred-Identity: <tel: +1-555-1001> P-Access-Network-Info:3GPP-GERAN-CS; Privacy: none From:Alice<sip:+15551001@example.com;user=phone>;tag=9fxced76sl Supported: gruuTo: sip:+15555551002@example.com;user=phone Call-ID:c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 70 Contact:<sip:alice@192.0.2.1> ;+sip.instance=“<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>” Content-Type: application/sdp Content-Length: *Bodylength goes here*Upon receipt of a 380 (Alternative Service) response to the SIP Invitemessage, the UE shall use the ICSRN that was provided in the 380(Alternative Service) response as the E.164 number to set up a CS callto. This E.164 number shall be in the contact header of the 380(Alternative Service) or in fact it could be in the XML body.

Upon receipt of the R-URI, the S-SCSF recognizes that the Invite is forthe IMS centralized services node that has been assigned to the UE andforwards it to the this AS node. IMS centralized service nodeconfiguration information includes (a) the ICSRN E.164 start addressnumber; and (b) number of ICSRN to be allocated or the last E.164 startaddress number. To allow for flexibility in numbering plan, there maybemore occurrences of (a) and (b) allowing pools of ICSRN to be allocatedfrom different number ranges. In addition to (a) and (b), otherconfiguration information may include (c) life time an ICSRN can livefor; and (d) quarantine time of an ICSRN—how long after an ICSRN hasbeen assigned back to the ICSRN pool it cannot be used for.

Behavior at the IMS centralized service node is discussed. If the IMScentralized services node receives an Invite that contains an R-URI isshall examine that R-URI to determine if that R-URI is associated with arequest to initiate a MO call over CS. An alternative implementation isthat the IMS centralized services node will examine theP-Access-Network-Info header. If it is set to GERAN-CS or some othervalue to indicate call-set-up over CS, the IMS centralized services nodeshall assume the received Invite shall be terminated here and thebehavior as follows shall take place.

The IMS centralized services node will assign a ICSRN to the receivedGRUU. The following represents a possible mapping of the ICSRN to theother information elements.

ICSRN -- GRUU P-Asserted ID(s) B-Number (SIP URI or Tel URI)The IMS centralized services node will respond to the INVITE requestwith a 380 (Alternative Service) response. An example of coding of thisresponse can be found below, which shall include the ICSRN, the RadioAccess type that the handover shall be made to that includes (but is notlimited to)“IEEE-802.11”/“IEEE-802.11a”/“IEEE-802.11b”/“IEEE-802.11g”/“3GPP-GERAN”/“3GPP-UTRAN-FDD”/“3GPP-UTRAN-TDD”/“ADSL”/“ADSL2”/“ADSL2+”/“RADSL”/“SDSL”/“HDSL”/“HDSL2”/“G.SHDSL”/“VDSL”/“IDSL”/“3GPP2-1X”/“3GPP2-1X-HRPD”/“DOCSIS”/token,3GPP-GERAN CS, 3GPP-GERAN PS, 3GPP-UTRAN CS, 3GPP-UTRAN PS, 802.11b,802.11a, 802.11g, EVDO, CDMA1X, WiMAX, etc. The ICSRN is also containedin the Contact Header. It will start a timer against the allocation ofthe ICSRN that will be cancelled on receipt of an Invite thatorigination was from a MGCF with the ICSRN as the R-URI. If the timerexpires the ICSRN shall be put into a quarantine pool.

If the IMS centralized services node receives a subsequent request fromthe same UE, identified by the GRUU in the Invite, the IMS centralizedservices node may do the following: (a) Resend the same ICSRN and resetthe timer; (b) Allocate a new ICSRN, start a timer associated with thatICSRN and put the old put into the quarantine pool; and (c) Reject therequest altogether and put the old put into the quarantine pool.

The following is exemplary code for coding a 380 Alternative ServiceResponse:

<!ELEMENT ICSRN EMPTY> <!ATTLIST ICSRN  TYPE (SIP_URI | Tel_URI)#REQUIRED > <!ELEMENT RAT EMPTY> <!ATTLIST RAT  TYPE (IEEE-802.11 |IEEE-802.11a | IEEE-802.11b | IEEE- 802.11g | 3GPP-GERAN |3GPP-UTRAN-FDD | 3GPP-UTRAN-TDD | ADSL | ADSL2 | ADSL2+ | RADSL | SDSL |HDSL | HDSL2 | G.SHDSL | VDSL | IDSL | 3GPP2-1X | 3GPP2-1X-HRPD | DOCSIS| token| 3GPP -GERAN CS | 3GPP -GERAN PS | 3GPP-UTRAN CS | 3GPP-UTRAN PS| EVDO | CDMA1X | WiMAX) #REQUIRED > Or <!ELEMENT AT EMPTY> <!ATTLIST AT TYPE (IEEE-802.11 | IEEE-802.11a | IEEE-802.11b \ IEEE- 802.11g |3GPP-GERAN | 3GPP-UTRAN-FDD | 3GPP-UTRAN-TDD | ADSL | ADSL2 | ADSL2+ |RADSL | SDSL | HDSL | HDSL2 | G.SHDSL | VDSL | IDSL | 3GPP2-1X |3GPP2-1X-HRPD | DOCSIS | token | 3GPP -GERAN CS | 3GPP -GERAN PS |3GPP-UTRAN CS | 3GPP-UTRAN PS | EVDO | CDMA1X | WiMAX) #REQUIRED > <?xmlversion=″1.0″?> <!-- Draft DTD for the IMS XML body. --> <!DOCTYPEims-3gpp [ <!-- ims-3gpp element: root element --> <!ELEMENT ims-3gpp(alternative-service?, service- info?)> <!ATTLIST ims-3gpp version CDATA#REQUIRED> <!-- service-info element: The transparent data received fromHSS for AS --> <!ELEMENT service-info (#PCDATA)> <!--alternative-service: alternative-service used in emergency sessions --><!ELEMENT alternative-service (type, reason)> <!ELEMENT type (emergency| vcc- domain-tx, MO call)> <!ELEMENT reason (#PCDATA)> <!ELEMENTvcc-domain-tx (uri?, access-type?, domain-type?) <!ELEMENT uri(#PCDATA)> <!ELEMENT access-type EMPTY> <!ATTLIST access-type access-technology (IEEE-802.11 | IEEE-802.11a | IEEE- 802.11b |IEEE-802.11g | 3GPP-GERAN | 3GPP-UTRAN-FDD | 3GPP- UTRAN-TDD | ADSL |ADSL2 | ADSL2+ | RADSL | SDSL | HDSL | HDSL2 | G.SHDSL | VDSL | IDSL |3GPP2-1X | 3GPP2-1X-HRPD | DOCSIS | token| 3GPP -GERAN CS | 3GPP -GERANPS | 3GPP-UTRAN CS | 3GPP-UTRAN PS | EVDO |CDMA1X | WiMAX) #REQUIRED ><!ELEMENT domain-type EMPTY> <!ATTLIST domain-type  domain (IMS | CS)#IMPLIED > ]> <vcc-domain-tx> <uri>tel:ffff</uri> <access-typeaccess-technology=”IEEE-802.11”/> <domain-type domain=”IMS”/></vcc-domain-tx> END

FIG. 4 depicts a block diagram of an embodiment of a mobilecommunication device operable as a wireless UE device, e.g., UE 302, forpurposes of the present patent disclosure. It will be recognized bythose skilled in the art upon reference hereto that although anembodiment of UE 302 may comprise an arrangement similar to one shown inFIG. 4, there can be a number of variations and modifications, inhardware, software or firmware, with respect to the various modulesdepicted. Accordingly, the arrangement of FIG. 4 should be taken asillustrative rather than limiting with respect to the embodiments of thepresent patent disclosure. A microprocessor 402 providing for theoverall control of an embodiment of UE 302 is operably coupled to acommunication subsystem 404 that is capable of multi-mode communications(e.g., CS domain, IP domain such as IMS, et cetera). The communicationsubsystem 404 generally includes one or more receivers 408 and one ormore transmitters 414 as well as associated components such as one ormore local oscillator (LO) modules 410 and a processing module such as adigital signal processor (DSP) 412. As will be apparent to those skilledin the field of communications, the particular design of thecommunication module 404 may be dependent upon the communicationsnetworks with which the mobile device is intended to operate (e.g., aCDMA network, a GSM network, WLAN, et cetera). Regardless of theparticular design, however, signals received by antenna 406 throughappropriate access infrastructure 405 (e.g., cellular base stationtowers, WLAN hot spots, etc.) are provided to receiver 408, which mayperform such common receiver functions as signal amplification,frequency down conversion, filtering, channel selection,analog-to-digital (A/D) conversion, and the like. Similarly, signals tobe transmitted are processed, including modulation and encoding, forexample, by DSP 412, and provided to transmitter 414 fordigital-to-analog (D/A) conversion, frequency up conversion, filtering,amplification and transmission over the air-radio interface via antenna416.

Microprocessor 402 may also interface with further device subsystemssuch as auxiliary input/output (I/O) 418, serial port 420, display 422,keyboard/keypad 424, speaker 426, microphone 428, random access memory(RAM) 430, a short-range communications subsystem 432, and any otherdevice subsystems, e.g., timer mechanisms, generally labeled asreference numeral 433. In this example, display 422, keyboard/keypad424, speaker 426, microphone 428 are part of the user interface of themobile communication device through which calls may be initiated by andmaintained for the end user. To control access, a SIM/RUIM 434 may alsobe provided in communication with the microprocessor 402. In oneimplementation, SIM/RUIM interface 434 is operable with a SIM/RUIM cardhaving a number of key configurations 444 and other information 446 suchas URIs as well as identification and subscriber-related data. Notethat, without a SIM/RUIM, the UE device is referred to as mobileequipment (ME) but techniques of the present disclosure are applicableto either device.

Operating system software and applicable service logic software may beembodied in a persistent storage module (i.e., non-volatile storage)such as Flash memory 435. In one implementation, Flash memory 435 may besegregated into different areas, e.g., storage area for computerprograms 436 (e.g., service processing logic), as well as data storageregions such as device state 437, address book 439, other personalinformation manager (PIM) data 441, and other data storage areasgenerally labeled as reference numeral 443. A transport stack 445 may beprovided to effectuate one or more appropriate radio-packet transportprotocols. In addition, a call control logic module 448 is provided forappropriate call message processing according to the present techniques,effectuating SIP-URI and call reference ID generation, validation,verification, and correlation with IMRNs, etc. as set forth hereinabove.

Thus, methods and apparatus for originating a Session InitiationProtocol (SIP) call from a user equipment (UE) device in a networkenvironment including a circuit-switched (CS) network and an IPmultimedia subsystem (IMS) network to a called party have beendescribed. When the SIP call is originated from the UE device in the CSnetwork domain, a SIP Invite message which includes a SIP UniformResource Indicator (URI) or Tele URI of the called party is sent fromthe UE device to an application server (AS) node in the IMS network. Atthe AS node, a pool of E.164 numbers are maintained as IP multimediarouting numbers (IMRNs) which are utilized for mapping to or otherwiseassociating with called party URIs. Thus, the AS node dynamicallyallocates a select E.164 number with respect to the called party's URIreceived from the UE device, and returns it to the UE device in a SIP380 (Alternative Service) Response message. Subsequently, thedynamically-allocated E.164 number is sent from the UE device in a callsetup message for identification of the URI at the AS node. Thus, thedynamically-allocated E.164 number is utilized for routing the SIP calltowards the called party upon interrogating the URI—IMRN mapping,whereupon it may be released back to the pool of IMRNs for future use.Appropriate timers may be provided at the device and AS node endpointsso that it can be verified whether a call reference number associatedwith the call remains valid (e.g. it has not timed out) or thedynamically-allocated IMRN remains valid (e.g. it has not timed out).Optionally, the released IMRN may be quarantined for a period of time.

At the AS node, the technique may include the acts of maintaining accessto a pool of E.164 numbers as IP multimedia routing numbers (IMRNs);receiving a SIP Invite message for a SIP call originating from a userequipment (UE) device through a circuit-switched network domain, the SIPInvite message having call information which includes a SIP URI or TelURI of the called party; selecting one of the E.164 numbers and storinga mapping between the selected E.164 number and the call information;causing a SIP 380 (Alternative Service) Response message to be sent tothe UE device in response to receiving the SIP Invite message, the SIP380 (Alternative Service) message including the selected E.164 number;and after the sending of the SIP 380 (Alternative Service) Responsemessage, receiving a call setup message from the UE device for the SIPcall, the call setup message having the selected E.164 number;identifying, with use of the selected E.164 number via the storedmapping, the URI identified from the call setup message; and causing aSIP session to be established with the called party with use of the URIidentified via the stored mapping.

It is believed that the operation and construction of the embodiments ofthe present patent application will be apparent from the DetailedDescription set forth above. While the exemplary embodiments shown anddescribed may have been characterized as being preferred, it should bereadily understood that various changes and modifications could be madetherein without departing from the scope of the present disclosure asset forth in the following claims.

What is claimed is:
 1. A method for an application server (AS) node, themethod comprising: receiving a first SIP Invite request from a mobilecommunication device, the first SIP Invite request having callinformation which includes a call reference number, a uniform resourceindicator (URI) of a called party and data used for determining whetherthe first SIP Invite request is for a bearer over a circuit-switched(CS) network; associating an E.164 number with the call information inthe first SIP Invite request; sending a SIP alternative service responseto the mobile communication device in response to receiving the firstSIP Invite request, the SIP alternative service response including theE.164 number and the call reference number; after sending the SIPalternative service response, receiving a call setup message from the CSnetwork, the call setup message having the E.164 number; verifying thatthe received E.164 number remains valid; identifying the callinformation based on the E.164 number; and sending, to the called party,a second SIP Invite request that includes the call information a secondcall information.
 2. The method of claim 1, further comprising:identifying the URI of the called party in a TARGET field of the firstSIP Invite request.
 3. The method of claim 1, wherein a URI field of thefirst SIP Invite request is populated with a public service identifier(PSI) of the AS node of an Internet Protocol (IP) multimedia subsystem(IMS) network.
 4. The method of claim 1, further comprising: reading thedata; and determining, based on the data, that the first SIP Inviterequest is for the bearer over the CS network.
 5. The method of claim 1,wherein the call setup message is another SIP Invite request.
 6. Anapplication server (AS) node comprising: a processor configured to:receive a first SIP Invite request from a mobile communication device,the first SIP Invite request having call information which includes acall reference number, a uniform resource indicator (URI) of a calledparty and data used for determining whether the first SIP Invite requestis for a bearer over a circuit-switched (CS) network;associatingassociate an E.164 number with the call information in thefirst SIP Invite request; send a SIP alternative service response to themobile communication device in response to receiving the first SIPInvite request, the SIP alternative service response including the E.164number and the call reference number; after sending the SIP alternativeservice response, receive a call setup message from the CS network, thecall setup message having the E.164 number; verify that the receivedE.164 number remains valid; identify the call information based on theE.164 number; and send, to the called party, a second SIP Invite requestthat includes the call information a second call information.
 7. The ASnode of claim 6, wherein the processor is further configured to identifythe URI of the called party in a TARGET field of the first SIP Inviterequest.
 8. The AS node of claim 6, wherein the processor is furtherconfigured to select the E.164 number by allocating the E.164 numberfrom a plurality of E.164 numbers.
 9. The AS node of claim 6, whereinthe processor is further configured to: read the data; and determine,based on the data, that the first SIP Invite request is for the bearerover the CS network.
 10. The AS node of claim 6, wherein the call setupmessage is another SIP Invite message.
 11. The method of claim 1,wherein the second call information comprises a second call referencenumber.
 12. The method of claim 1, wherein the second call informationcomprises a second uniform resource indicator (URI).
 13. The method ofclaim 12, wherein the URI in the first SIP Invite is a first URI and thesecond URI is the first URI.
 14. The AS node of claim 6, wherein thesecond call information comprises a second call reference number. 15.The AS node of claim 6, wherein the second call information comprises asecond uniform resource indicator (URI).
 16. The AS node of claim 15,wherein the URI in the first SIP Invite is a first URI and the secondURI is the first URI.